fix(desktop): give Windows agent children a usable PATH and start dev#2506
Open
al3rez wants to merge 1 commit into
Open
fix(desktop): give Windows agent children a usable PATH and start dev#2506al3rez wants to merge 1 commit into
al3rez wants to merge 1 commit into
Conversation
Two things stop Buzz working on Windows.
Managed agents get a PATH assembled from Buzz's own directories plus the user's
login-shell PATH. On Windows that login-shell PATH is always None, because Git
Bash reports POSIX colon-delimited entries that would be meaningless to a native
child. The comment there says the child inherits the real Windows PATH instead,
but it does not: the spawn calls `Command::env("PATH", ..)`, which replaces the
inherited value rather than extending it. The child ends up with Buzz's managed
directories and nothing else, so node, npm and git all disappear and every npm
`.cmd` shim dies immediately:
'"node"' is not recognized as an internal or external command
ERROR buzz_acp: agent initialize failed: Agent process exited unexpectedly
Error: all 24 agents failed to start — cannot continue
Append the current process PATH on Windows when no shell PATH was supplied,
gated on local context so callers passing nothing still get None back instead of
a PATH manufactured out of ambient process state.
Separately, `beforeDevCommand` runs `exec ./node_modules/.bin/vite`. `exec` is a
POSIX shell builtin and Tauri runs the script through cmd.exe on Windows, so
`tauri dev` cannot start at all:
'exec' is not recognized as an internal or external command
The "beforeDevCommand" terminated with a non-zero status code.
Invoke Vite through node instead, which works on every platform. This does drop
the `exec` optimisation on Unix, where it saved an intermediate shell process,
so it is worth a look from someone who runs the macOS dev loop daily.
Signed-off-by: Alireza Bashiri <al3rez@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two separate things stop Buzz working on Windows. Both are small, but together they make the desktop app unusable there.
Agents can't find node
Every managed agent dies the moment it starts. From
%APPDATA%\xyz.block.buzz.app\agents\logs\:build_augmented_pathassembles the child's PATH from Buzz's managed directories plus the user's login-shell PATH. On Windows the latter is alwaysNone—fetch_login_shell_path_innerreturns early there, correctly, since Git Bash reports POSIX colon-delimited entries (/c/Users/...) that a native child can't use.The comment says children "inherit the real Windows PATH instead." They don't.
runtime.rsdoescommand.env("PATH", path), which replaces the inherited value rather than extending it, so the agent ends up with Buzz's managed directories and nothing else. No node, no npm, no git. The npm.cmdshims fail on their first line.This appends the process PATH on Windows when no shell PATH was supplied. It's gated on
!parts.is_empty()so callers that pass no local context still getNoneback, matching the existing rule about not manufacturing a PATH out of ambient state.tauri devdoesn't startbeforeDevCommandisexec ./node_modules/.bin/vite.execis a POSIX shell builtin, and Tauri runs the script throughcmd.exeon Windows. Calling Vite through node works everywhere.One caveat worth a review from someone on the macOS dev loop:
execwas presumably there to avoid an intermediate shell process so signals reach Vite directly. This change gives that up on Unix. If that matters more than I think, the alternative is a platform-specific config file, which is uglier but keeps the current behaviour.Testing
Windows 11 (26100). Two new unit tests cover the PATH change: one asserts the process PATH is appended after the managed directories, the other that no PATH is manufactured without local context.
cargo test -p buzz-desktop --lib managed_agents::runtime::pathpasses, and the existing Unix tests are untouched.For the dev command,
pnpm exec tauri devnow starts cleanly with no platform-specific config override:Neither change affects macOS or Linux behaviour: the PATH addition is behind
#[cfg(windows)], and on Unixshell_pathis alwaysSome, so the new branch can't be reached even if the cfg were removed.